We are IntechOpen, the world's leading publisher of Open Access books Built by scientists, for scientists

Open access books available 5,300

130,000 155M

International authors and editors

Downloads

Our authors are among the

most cited scientists 154 TOP 1%

Selection of our books indexed in the Book Citation Index in Web of Science™ Core Collection (BKCI)

# Interested in publishing with us? Contact book.department@intechopen.com

Numbers displayed above are based on latest data collected. For more information visit www.intechopen.com

# **MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems**

Oriol Font-Bach, Antonio Pascual-Iserte, Nikolaos Bartzoudis and David López Bueno

Additional information is available at the end of the chapter

http://dx.doi.org/10.5772/48706

# **1. Introduction**

The ability to verify the capacity gains of novel signal processing techniques or the performance of new communication standards is one of the main research and development drivers of both academic and industrial entities. In this context, the signal processing community has adopted MATLAB as a flexible modelling, simulating and testing software development environment. MATLAB includes numerous toolboxes, open-source code and pre-compiled libraries, which facilitate the design of complex systems using high-level models and provides the means for rapid verification of signal processing algorithms and systems in a user-controlled environment. The growing number of its add-on features allows MATLAB to fill the gap between these high-level models and the physical implementation of systems; e.g., a real-time Field Programmable Array (FPGA)-based prototype. Moreover, the functionality of MATLAB is significantly extended with the use of Simulink [1], which serves as a schematic-entry design and programming environment. The integration of the System Generator blockset of Xilinx [2] to Simulink and the direct linking of the latter with the Xilinx FPGA-design toolchain enriches the target use-cases of the software. This approach allows the creation of FPGA binary executables from high-level models. MATLAB is also one of the most popular software-modelling environments, whose functionality is commonly interfaced nowadays with instruments to provide connectivity, control and programming solutions for rapid prototyping and testing. In fact, MATLAB scripts are increasingly used to program a wide variety of testing, signal generation and signal analysis hardware instruments. Thus, the programming versatility of MATLAB allows it to be used as a key software component in complex testbeds, which comprise a multitude of software programming interfaces and heterogeneous hardware instruments. The role of such testbeds is crucial because they enable the prototyping and validation of advanced research concepts under realistic conditions,

©2012 Bartzoudis et al., licensee InTech. This is an open access chapter distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0),which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

#### 2 Will-be-set-by-IN-TECH 188 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

providing at the same time a detailed account of hardware requirements and implementation feasibility.

The present chapter aims at describing how MATLAB can be used as a design and verification tool in the different phases of migrating a high-level model to a real-time hardware prototype, using as a case study the implementation of a real-life wireless communication system. The chapter proposes a generic design methodology and, finally, provides a practical case study related to the implementation of a real-time Multiple Input Multiple Output (MIMO) mobile WiMAX (i.e., IEEE 802.16e) system [3, 4].

### **1.1. Considered development scenarios**

Real-time system-prototyping using FPGA devices is a painstaking and time-consuming process that goes beyond a controlled computer simulation. In this context, MATLAB is having a manifold contribution as a design and validation tool. In order to successfully leverage the advices, techniques and design methodology, it is required to define the specific development scenarios that have to be considered by digital design developers.

It is important to note that this chapter will not cover model-based, MATLAB-to-Register Transfer Level (RTL) design flows (e.g., by using the Simulink and System Generator tools). Adversely, a custom-code programming strategy will be followed, where the user carefully designs each component of the system and takes into account the constraints of real-world hardware and signals. Our focus is to unveil the key role that MATLAB plays when the design objective is the creation of custom Hardware Description Language (HDL) code (e.g., Very High Speed Integrated Circuit - VHSIC - HDL, VHDL) that targets high-performance wireless communication prototypes. In fact, converting a MATLAB model into a working VHDL code for such FPGA-based prototypes requires a considerable effort. Although the automatic MATLAB-to-HDL conversion is becoming increasingly popular, its efficiency is still under scrutiny by the FPGA designer community [5]. The main concern raised is that the MATLAB-to-HDL automatic conversion is not yet mature enough to cover the needs of processing demanding FPGA-based systems, where performance and constraints imposed by the size and the embedded resources of the target device, may occasionally render this option unsuitable. The direct MATLAB-to-HDL translation accepts only very limited constructs that can be automatically translated into hardware [6]. Other approaches, involving an intermediate stage of Matlab-to-C code generation, can be used as an alternative. The produced C code is consequently processed by C-to-HDL synthesis tools subject to certain modifications (i.e., the generated C code contains unsupported constructs that prevent a seamless translation to HDL code).

As already mentioned, the automatically-produced HDL code is usually not as efficient as the custom hand-written HDL one. This difference is becoming a significant factor to be considered when stringent FPGA area utilization conditions apply or when performance and achievable clock frequencies do matter [7]. The modern FPGA devices and the corresponding synthesis tools seem to address the issues mentioned before. This is due to the extraordinary capacities of the new devices in terms of embedded resources (logic, memories dedicated Digital Signal Processing - DSP - logic) and the significant improvement of the FPGA design and implementation tools. However, it is anticipated that the FPGA-based prototyping and the respective FPGA design tools are due to be challenged soon by the constantly aggregated performance requirements and algorithmic complexity of next generation wireless MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 3 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 189

communication systems. Therefore, an incremental design approach based on custom-HDL coding is once again expected to be the most reliable solution to sort out well-established digital design problems (i.e., dense FPGA designs with compute intensive requirements and hard to achieve timing constraints [8]). The only difference is that the complexity of such problems is scaled because of the massive amount of FPGA logic, memories and embedded components that need to be addressed. Custom HDL coding provides the means to control every important aspect of the design, which requires an in-depth knowledge of the low-level RTL architecture.

The design and validation principles presented herein could be applied in many digital-design cases. Nonetheless, the application-domain will be narrowed down to well-characterized case studies, in order to help the reader to assimilate the described concepts, methodology and examples. Thus, this chapter explores the uses of MATLAB when the custom-HDL design flow is employed for the prototyping of systems with design and implementation requirements similar to the ones described next:

#### I Real-time system prototyping


#### 4 Will-be-set-by-IN-TECH 190 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

	- *Advanced wireless communication system*: The goal in this case is the rapid prototyping of advanced techniques able to satisfy the requirements of future wireless communication systems. As it will be detailed in the following lines, the prototypes that principally operate offline make a series of assumptions to simplify the testing and deployment conditions and remove or ignore real-life implementation constraints. This inevitably results in a partial validation of the systems under test, especially for those cases where exhaustive offline data processing is practically impossible. Nonetheless, their contribution is also significant because they enable the design and preliminary experimental evaluation of algorithms beyond the state-of-the-art.
	- *Off-line operation*: One of the main drivers of rapid prototyping is based on hybrid experimental testbeds that combine real-time processing and offline software-based post-processing. Such platforms, make use of commercial Vector Signal Generator (VSG) instruments equipped with arbitrary waveform generators. These are configured with user-generated MATLAB vectors, which represent the output of a baseband transmitter and eventually produce a real-time RF signal that is transmitted using either antennas or a direct cable connection. Offline testbeds may also use a RF channel emulator or other instruments that combine signal generation and channel fading. On the receiver side the data is stored in large buffers (e.g., FPGA) and retrieved in order to be post-processed offline. The captured signals are used as test vectors that facilitate the modelling of the baseband signal processing algorithms of the receiver (i.e., MATLAB high-level model of the system). This prototyping methodology allows the rapid verification of the functionality and performance of

algorithms. However, certain data capturing and post-processing limitations apply, especially when the testing requires reception of long data frames under high mobility conditions. In fact, although offline prototyping accelerates the design and testing of algorithms, it is important to understand its foundations and design particularities e.g., unconstrained computational and storage resources, unlimited precision using floating-point implementation, no need to account for real-life implementation constraints or the complexity of the control plane, perfectly synchronized signals or ideal channels are typically assumed. Thus it is clear that in order to achieve a thorough analysis of the implementation cost and feasibility of the target system (especially in scenarios requiring dynamic responsiveness or high mobility), real-time prototyping has to be employed.


### **1.2. The role of MATLAB in the design and validation process**

As it has been described in the previous section, system-prototyping involving FPGAs and other specialized hardware equipment is subject to non idealities and certain signal impairments, which are not usually considered in a computer-based simulation (i.e., high-level models). Moreover, the heterogeneous hardware boards used for the prototyping of high performance real-time systems impose a series of hardware constraints in terms of processing capacity, available memory, maximum achievable clock frequency, I/O interfacing, DAC/ADC resolution and power consumption.

In the following sections, it will be shown how the previously described operating conditions and constraints can be either modelled or considered in MATLAB throughout the design and implementation process. The goal is to demonstrate the plural contribution of MATLAB in the FPGA-based rapid prototyping, beyond its well-established function as a high-level modelling tool:

I *Definition of system requirements*: Apart from its traditional operating perception, MATLAB can be used as a key companion throughout the analysis of system requirements in terms of computational resources and cost (e.g., implementation complexity, optimal hardware platform selection). Once the deployment scenario and specifications are

#### 6 Will-be-set-by-IN-TECH 192 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

strictly defined (e.g., operating frequencies, channel bandwidth, channel specifications, sampling frequencies, DAC-ADC resolution) the high-level MATLAB model of the system can be modified to satisfy real-life system characteristics, according to the following key points:


The process of mapping a high-level MATLAB model to HDL logic and consequently to FPGA-based hardware is a complex and costly process, where many crucial decisions need to be taken. These include among others the environment where the system will be deployed, the expected operating conditions and the target implementation technology. MATLAB can be easily interfaced with third-party EDA tools and hardware equipment [14], a fact that facilitates this decision-making process. Additionally, the use of MATLAB in all prototyping-stages makes easier the interaction between different design-teams by providing a common working framework.

# **2. Design methodology**

The design, implementation and on-board testing of high performance wireless communication systems under realistic conditions implies an undertaking with high stakes. Thus, the adoption of a well-structured design, implementation and validation methodology is a paramount requirement. The aim of this section is to offer an insight to a robust, yet generic, methodology, which demonstrates the contribution of MATLAB during the FPGA prototyping stages using a custom HDL design entry. The effectiveness of the proposed methodology is analysed using a practical case study, which involves the prototyping of a real-time MIMO mobile WiMAX system.

A fundamental guideline that applies throughout the design, implementation and on-board validation phases is a multi-stage testing strategy (Fig. 1). This starts from a baseband-to-baseband system testing under ideal conditions. The latter is performed both in simulation-time (MATLAB and consequently HDL-based) and at real-time in the target hardware platform using a direct connection of the transmitter and receiver. The scenario can then be augmented by adding the conversion stages (i.e., ADC and DAC). This implies re-simulating the MATLAB and HDL code and finally validate the FPGA implementation in real-time (i.e., connecting via a cable the output of the DAC device with the input of the ADC device). The final testing stage can be divided in two sub-stages; the first includes a direct cable connection of the RF front-ends and the second the inclusion of channel either by using antennas or a real-time channel emulator (both sub-stages can be priorly simulated in MATLAB and in HDL). This incremental testing approach allows the step-by-step characterization of the system.

# **2.1. Starting point**

The development of a processing demanding real-time wireless communication system requires a wide range of skills, resources and time. A commonly accepted commencing point is the design of a baseline version of the target system, which complies with the following design requirements:


#### 8 Will-be-set-by-IN-TECH 194 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

**Figure 1.** Multi-stage testing strategy

Once the baseline system-model is designed and validated, the proposed methodology can adjust the granularity of the system by accommodating more advanced features.

## **2.2. Proposed methodology**

This section gives the details of the proposed design methodology, which is depicted in Fig. 2.


<sup>1</sup> The described functionality is available, for instance, on the VSGs provided by Agilent (*http://www.agilent.com*) or Rode & Schwarz (*http://www.rohde-schwarz.com)*. Further information on other hardware manufacturers supporting MATLAB communication may be found in *http://www.mathworks.com/products/instrument/hardware*.

**Figure 2.** Proposed design, implementation and validation methodology

is directly interfaced with advanced instrumentation to produce a real-time signal. This signal can be then processed by specific testing hardware (e.g., signal analysers, digital oscilloscopes), which communicate with proprietary third-party software in order to perform standard-compliance tests. Additionally, the transmitted signal can be introduced via a cable connection to the receiver's RF down-converters (i.e., no channel should be used at this initial design stage) and after passing from the ADC stage at the receiver's acquisition boards, it can be retrieved using the FPGA devices and dedicated external memories of the baseband signal processing boards. The captured data constitute realistic test vectors that can be used for the development of the MATLAB model of the receiver, whereas the whole testing procedure permits a refinement of the initial transmitter model (see points IV and V). The testing setup described before could also include specialized equipment that add realistic signal impairments (e.g., real-time emulation of a selected channel, addition of noise or of Carrier Frequency Offset - CFO). However, such operating conditions make unreliable the capturing of test-vectors until the digital front-end of the receiver is developed and tested at the target FPGA board.

III *Basic receiver modelling*: The next step is the modelling of the signal processing algorithms at the receiver side. As in the case of the transmitter, the ideal MATLAB model of the receiver uses floating-point logic and does not have any design limitations in terms of processing and memory resources. The functional testing of the complete system is conducted by running a MATLAB simulation of the transmitter and receiver models

#### 10 Will-be-set-by-IN-TECH 196 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

(i.e., ideal baseband-to-baseband signal). This could be extended by using the test vectors captured in the previous step (i.e., hardware-validated MATLAB model of the transmitter). Although the design is still not constrained by the limitations of the entire hardware processing platform, the performance of different algorithms could be studied, including those whose computational complexity makes their real-time prototyping challenging. The designer has therefore the opportunity to estimate the ideal performance of the overall system.

	- *RTL-implementation awareness*: it is widely known that not all MATLAB structures or functions are implementable in an FPGA. Even if equivalent HDL constructs exist, they are used during simulation time but do not serve for logic synthesis (e.g., a for-loop construct with undefined number of iterations). Moreover, MATLAB includes several pre-compiled DSP functions (e.g., Fast Fourier Transform - FFT) and provides abstract arithmetic operators (i.e., the user calls the same operator independently of the type of the operands). For instance, the '∗' operator provides the multiplication for integer, real or complex numbers, arrays and matrices. Although these MATLAB features provide a powerful workbench for users, it is common quite a mistake to underestimate the computational complexity and the internal arithmetic calculations of such operations, especially when they are meant to be mapped on a real-time RTL-based implementation (see example 2.1). It is therefore a key design requirement to evaluate the implementability and arithmetic complexity of the algorithms comprising the target system, in relation to the maximum processing and memory capacity of the target FPGA device. This usually gives a first idea of which design partitioning strategy can be followed (e.g., using various FPGA devices or a combination of FPGA devices and DSP microprocessors). The importance of this evaluation stage for the mapping of the MATLAB model to RTL code is crucial and may result in selecting different algorithms and lightweight versions of pre-compiled arithmetic functions. Another important task is to estimate the storage and intercommunication needs. This is made feasible by including in the MATLAB model a high-level representation of the memory and control planes.

MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 11 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 197


<sup>2</sup> It is useful to mention that specific floating-point arithmetic libraries, Intellectual Property (IP) cores, embedded microprocessors and other dedicated processing components can be used in FPGA devices to serve the needs of particular applications that require this type of arithmetic operations [15, 16]

**Example 2.1**: let's consider the simple multiplication of two complex numbers, *a* = 2.5 + 3.2*i* and *b* = 1.7 − 4.5*i*. In MATLAB a user would simply type 'c=a \* b' abstracting away the underlying calculation. However, when considering a RTL design many other aspects must be considered.

First, let us assume a dynamic range of input samples that satisfy the (−8, 8) margin. Also let us consider a binary representation of samples with 16 bits, where 4 bits are used to represent the sign and the integer part and the remaining bits are used to represent the fractional part. The I and Q components of the complex numbers have to be represented separately. This can be modelled in MATLAB using the quantizer, num2bin and bin2num functions of the fixed-point toolbox:

q = quantizer([16 12]);

I\_a = num2bin(q,real(a)); Q\_a = num2bin(q,imag(a)); I\_b = num2bin(q,real(b)); Q\_b = num2bin(q,imag(b));

Furthermore, the complex multiplication has to be broken down to basic operations. In MATLAB this can be done as follows:

```
I_c = bin2num(q,I_a)*bin2num(q,I_b) - bin2num(q,Q_a)*
bin2num(q,Q_b);
Q_c = bin2num(q,Q_a)*bin2num(q,I_b) + bin2num(q,I_a)*
bin2num(q,Q_b);
```

```
A first approximation of the error introduced by quantization can be measured with
a simple subtraction: quant_loss_I = real(c) - I_c; quant_loss_Q =
imag(c) - Q_c;
```
Moreover, each arithmetic operation in RTL coding results in a bit-width grow: e.g., the multiplication of two *N*-bit operands results in *2N* bits and the addition of two *N*-bit operands results in *N+1* bits. Therefore, RTL coding implies that each of the previously described intermediate operations has to be considered separately:

intermediate\_op1 = I\_a \* I\_b, results in 32 bits intermediate\_op2 = Q\_a \* Q\_b, results in 32 bits intermediate\_op3 = intermediate\_op1 - intermediate\_op2, results in 33 bits

To sum up, a quantization adjustment (i.e., bit-alignment in case the bit-width of the different operands grows differently) and/or a data-truncation will be required between the different intermediate calculations to limit the overall computational complexity. Additionally, in order to achieve a better timing performance of the FPGA design, the intermediate calculations of complex operations are placed in different clocked-processes: i.e., the calculation of 'intermediate\_op3' 'intermediate\_op1' and 'intermediate\_op2' would be placed in a different clocked process. Therefore, a latency of one clock cycle would be introduced at each intermediate calculation. Although the bit-width growth and the introduced latencies are not modelled in MATLAB, it is highly recommended to analyse such aspects in order to assess the system's complexity. A complex calculation may result in a change of the quantization, which in turn will require further modifications of the MATLAB model.

MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 13 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 199


The end of a major design cycle is reached when the performance of the RTL prototype is finally validated on real-time hardware and does not require any further modifications. This gives the opportunity to the system designer to introduce additional features by iterating over the previously described methodology. The proposed incremental design approach implies a relative low effort to augment the features of a working prototype. This is mainly due to the fact that a modular and reusable code is already available, while at the same time the critical parts of the design and the system bottlenecks are well defined. The same applies to the hardware platform which is already thoroughly studied and characterized.

# **3. A practical case study**

This final section presents a practical case study of the manifold contribution of MATLAB throughout the entire design, development and prototyping stages of a real-time mobile WiMAX system [3, 4]. The use-cases focus on the Single Input Single Output (SISO) configuration of the system [17] that features one antenna at the transmitter and receiver sides respectively. Taking as an exemplar basis the development of the SISO system, the presented incremental design methodology can be reused to develop the MIMO system, which however is not covered in this chapter. The main specifications of the target system are summarized in table 1.

The GEDOMIS® testbed (see Fig. 3), was used to prototype and validate the system described in this chapter. GEDOMIS® features multiple APIs, dedicated signal analysis software tools

14 Will-be-set-by-IN-TECH 200 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

**Table 1.** Basic OFDM and PHY-layer specifications of the described system.

and a heterogeneous hardware setup. The latter comprises signal generation equipment, multi-channel signal conversion boards, a real-time radio channel emulator and FPGA-based baseband signal processing boards [18]. The examples detailed in the remaining of the chapter do follow the previously proposed multi-stage testing strategy (see Fig. 1) and do not always require the use of the full set-up of this testbed.

**Figure 3.** The GEDOMIS® testbed setup.

**Figure 4.** Basic architecture of the SISO transmitter and receiver systems.

## **3.1. PHY-layer prototype of a single antenna mobile WiMAX transceiver**

Fig. 4 shows a simplified functional block diagram of the SISO mobile WiMAX system. Taking as a reference the design methodology presented before, this section gives an example of the MATLAB usage in each prototyping stage.

I *Basic transmitter modelling*: The first task is the accurate definition of the OFDM-based frame structure. Thus, it has to be identified the basic function of the different frequency subcarriers within each OFDM symbol. In our case, the frame is structured according to the Partial Used Subcarrier (PUSC) and the AMC subcarrier permutation schemes, which are defined in the mobile WiMAX standard [19]. The main characteristics of both OFDM symbol structures are summarized in table 2. Example 3.1 shows the MATLAB-modelling of the processing block responsible for inserting the pilot subcarriers, the DC and the guard bands, according to the mobile WiMAX specifications. The additional subcarrier organization and permutation operations required by the WiMAX standard can be easily designed in MATLAB-space. Finally, the use of a standard inverse FFT function provides the ideal I/Q baseband outputs of the transmitter (i.e., floating-point values).

**Table 2.** Principal parameters of the PUSC and AMC permutation schemes.

16 Will-be-set-by-IN-TECH 202 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

```
Example 3.1: Fig. 5 shows the pilot distribution in the PUSC permutation scheme,
described in the mobile WiMAX standard.
Figure 5. Location of the pilot symbols in the PUSC permutation scheme.
Taking into account this pilot distribution, the following MATLAB code represents the
insertion of the pilot tones in a PUSC-structured OFDM frame:
%The PUSC-formatted OFDM symbols (i.e., outputs of the block in
charge of the IEEE 802.16e-related operations) are loaded in the
variable 'mWiMAX_PUSC_data'.
load('mWiMAX_PUSC_data')
PUSC_zone_length=30;
%There will be 240 pilots per OFDM symbol.
pilot=4/3+j*0; %Pilot value defined by the WiMAX standard.
%Each PUSC OFDM symbol contains 120 clusters of 12 contiguous
data subcarriers, where 2 pilots will be added.
evenSymb=1;
data_and_pilots=[];
for symb_index=0:PUSC_zone_length-1
symb_offset=symb_index*120*12;
ofdm_symbol=mWiMAX_PUSC_data(symb_offset+1:symb_offset+120*12);
cluster=[];
pilotCluster=[];
for cluster_index=0:119
subc_offset=cluster_index*12+1;
cluster=ofdm_symbol(subc_offset:subc_offset+11);
if evenSymb
pilotClus=[cluster(1:4) pilot cluster(5:7) pilot cluster(8:12)];
else
pilotClus=[pilot cluster(1:11) pilot cluster(12)];
end
ofdm_symbol=[ofdm_symbol pilotClus];
end
data_and_pilots=[data_and_pilots ofdm_symbol];
evenSymb=mod(evenSymb+1,2);
end
%A total of 368 null subcarriers are inserted.
ofdm_symbol=[zeros(1,184) ofdm_symbol(1:840) 0
ofdm_symbol(841:1680) zeros(1,183)];
```
MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 17 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 203

II *Hardware-validation of the baseband transmitter model*: As already described before, the I/Q output vectors of the MATLAB model of the ideal transmitter can be stored (separately) in a MATLAB file. The latter can be downloaded to an internal memory of a VSG instrument (as described in Example 3.2). The VSG can be programmed to use these vectors in order to produce a real-time RF signal. This is made feasible by exploiting its embedded arbitrary waveform generator, DAC devices and RF upconversion circuitry. The validation of this signal using third party software tools and hardware instruments is very important, considering that several signal impairments and hardware constraints can be identified during early design stages.

**Example 3.2**: The first step for the prototyping and testing of the ideal transmitter MATLAB model using off-line testbed principles, requires the storage of the output I/Q components in two files.

```
%The frequency-domain data produced by the baseband transmitter
(i.e., before the IFFT) is loaded in the variable 'BB_data'.
load('BB_data')
```

```
%A short silence period precedes each frame.
silence_length=2560*5;
transmitted_signal=zeros(silence_period_length,1);
```

```
%The frame is composed by a preamble and 48 OFDM symbols.
for symb_index = 1:49
BB_ofdm_symbol=BB_data(2048*(symb_index-1)+1:(2048*symb_index));
%Conversion from frequency to time domain.
time_ofdm_symbol=zeros(512+2048,1);
time_ofdm_symbol(513:end)=ifft(BB_ofdm_symbol);
```

```
%Inclusion of the CP (i.e, the CP is a copy of the last 512
symbols of the OFDMA symbol).
preamble_length=512;
time_ofdm_symbol(1:preamble_length)=time_ofdm_symbol(1537:end);
transmitted_signal=[transmitted_signal; time_ofdm_symbol];
```

```
%I/Q component extraction.
custom_Tx_I=real(transmitted_signal);
custom_Tx_Q=imag(transmitted_signal);
```
end

```
%Creation of the 'custom_Tx_frame.mat' file to stimulate the VSG.
save('custom_Tx_frame.mat', 'custom_Tx_I', 'custom_Tx_Q');
```
Fig. 6, 7 and 8 show the configuration of the Agilent Signal Studio Toolkit. The latter is the software programming interface used to configure an Agilent E4438C VSG with the 'custom\_Tx\_frame.mat' file.

18 Will-be-set-by-IN-TECH 204 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

**Figure 9.** As it can be observed, the deviation between the ideal and the estimated channel is notable when using a linear interpolation, which accounts only for the two closest pilots for each subcarrier. On the contrary, the obtained results are better when applying a quadratic interpolation approach which uses three neighbouring pilots in the calculations.

Using a RF-to-RF cable connection data can be captured at the receiver baseband boards. This provides realistic test vectors that will be later used to design and debug the MATLAB model of the receiver.

III *Basic receiver modelling*: The first step is to model the ideal received signal. In this sense, it is assumed that the received signal is identical with the transmitted one, without making use of quantizations or accounting for signal-impairments. In other words, an ideal baseband-to-baseband communication is modelled as follows:

$$
\mathfrak{x}(t) = \mathfrak{x}(t), \tag{1}
$$

where *x*(*t*) represents the equivalent transmitted baseband signal.

The modelling of the receiver is based on WiMAX-defined processing functions (e.g., permutation of the subcarriers) and common signal processing operations (e.g., FFT). MATLAB provides the ideal modelling environment to compare the performance tradeoffs of different signal processing algorithms. As an example, Fig. 9 shows the comparison of a linear and a quadratic interpolation for a pilot-based channel estimation algorithm. This type of algorithm design and benchmarking allows the designer to make early decisions tailored for the specifications of the target hardware platform. Nonetheless, the validation of the critical parts of the receiver, such as the synchronization or the channel estimation requires a signal model that is closer to real-world conditions (i.e., accounting for impairments and hardware constraints). Once this modified version of the received signal is available, the designer is able to make a precise selection of algorithms that are suitable for the anticipated channel conditions and the characteristics of the target hardware platform.

IV *Signal impairment modelling*: Having already modelled the ideal system, the next step is to modify the signal model to include the expected signal impairments. This requires the analysis of the main specifications and performance of the target hardware. In the test-case described herein, certain signal impairments such as the I/Q gain and phase imbalances or LO drifts are ignored because of the performance indicators and specifications of the equipment comprising the GEDOMIS® testbed. It is important however that each designer exhaustively examines the complete set of potential signal impairments and ignore only those that have negligible effects to the received signal. This procedure is subject to generic signal processing and propagation principles, but also requires a hardware-specific analysis of potential impairments (i.e., different for each testbed). In our case, the resulting refined received signal model at the output of the RF down-converters can be expressed as follows:

$$\mathcal{L}(t) = \Re\{\mathbf{x}(t) \cdot e^{j2\Pi(f\_{IF} + \Delta f)t}\} + A \cdot \cos(2\Pi(f\_{IF} + \Delta f)t + \varphi) + w(t),\tag{2}$$

where *x*(*t*) represents the useful part of the received baseband signal, *fIF* is the Intermediate Frequency (IF), ∆*f* is the Carrier Frequency Offset (CFO), *A* · *cos*(2Π(*fIF* + ∆*f*)*t* + *ϕ*) represents the unwanted residual carrier located at the center of the useful signal-spectrum (i.e., introduced by the LO coupling at the transmitter) and, finally, *w*(*t*) is the Gaussian noise. The useful part of the received baseband signal can be expressed as:

$$\mathfrak{x}(t) = \mathfrak{x}(t) \star H(t), \qquad \bigsqcup \tag{3}$$

where *x*˜(*t*) is the equivalent transmitted baseband signal and *H*(*t*) is the equivalent baseband of the time impulse response of the channel between the transmit and receive antennas. Example 3.3 shows the MATLAB model of the refined signal shown in equation (2). Additionally, other aspects related to the RF transmission, reception and downconversion of the signal are also contemplated (e.g., oversampling).

**Example 3.3**: MATLAB code for the signal impairment modelling.

```
%A custom IFFT function, providing an oversampled output is
required (i.e., the ADCs are oversampling by 4).
function samples = ifft_x4oversamp(BB_ofdm_symbol)
temp_symbols = zeros(8192,1);
temp_symbols(1:1024) = BB_ofdm_symbol(1:1024);
temp_symbols((8192-1024+1):8192) = BB_ofdm_symbol(1025:2048);
samples = ifft(temp_symbols,8192);
%----- function end -----
%To simulate the channel a coefficients file will be used. The
channel will be loaded in the variable 'channel'.
load('channel_coefficients')
%The frequency-domain data produced by the baseband transmitter
(i.e., before the IFFT) is loaded in the variable 'BB_data'.
load('BB_data')
%A short silence period precedes each frame: now we have to
account for the over-sampling of the ADCs.
silence_length=2560*5*4;
transmitted_signal=zeros(silence_period_length,1);
%The frame is composed by a preamble and 48 OFDM symbols.
for symb_index = 1:49
BB_ofdm_symbol=BB_data(2048*(symb_index-1)+1:(2048*symb_index));
%Introduction of the LO coupling (i.e., DC carrier is not 0).
BB_ofdm_symbol(1)=2;
```
MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 21 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 207

```
%Conversion from frequency to time domain.
time_ofdm_symbol=zeros(2048+8192,1);
time_ofdm_symbol(2049:end)=ifft_x4oversamp(BB_ofdm_symbol);
%Inclusion of the CP (i.e, the CP is a copy of the last 512
symbols of the OFDMA symbol - oversampled by 4).
preamble_length=512*4;
time_ofdm_symbol(1:preamble_length)=time_ofdm_symbol(8193:end);
transmitted_signal=[transmitted_signal; time_ofdm_symbol];
end
%The modelled CFO will be equivalent to a third of the
intercarrier separation.
eps_freq=-1/3;
%Convolution of the frequency domain signal with the channel and
inclusion of the CFO and the noise.
SNR=25;
first_sample=silence_length+preamble_length+1;
mean_power = mean(abs(transmitted_signal(first_sample:end)).ˆ2);
noise_power = mean_power/(10ˆ(SNR/10));
received_signal = conv(transmitted_signal,channel);
rand_I=randn(size(received_signal));
rand_Q=randn(size(received_signal));
received_signal = received_signal+sqrt(noise_power/2)*(rand_I +
j*rand_Q);
received_signal = real(received_signal.*exp(j*2*pi*((156.8 +
(eps_freq*22.4/2048))*(1:length(received_signal))'/89.6)));
```
V *System model refinement*: In order to have a MATLAB model that provides a close match to the prerequisites of RTL coding, further modifications and refinements have to be conducted. This principally involves the emulation of fixed-point arithmetic in specific outputs of the MATLAB model. The trade-off between resulting precision and computational complexity has to be investigated. The more bits used to represent the fixed-point data, the more precision is achieved in the arithmetic operations. Considering that the prototyping target is a high performance real-time wireless communication system, it is required to use additional bits for the representation of signals, which consequently increases the FPGA processing and memory requirements. Different quantizations can be tested to analyse their effect both on independent processing stages, as well as on the overall system performance. An indicative example is when 16-bit words are used for the intermediate calculations of a custom MATLAB FFT function, featuring a radix-2 butterfly structure. This results in an aggregate quantization loss of 87 · 10−<sup>2</sup> . The equivalent loss when using 32-bit words is reduced down to 13 · 10−<sup>7</sup> . By inserting the quantized results to each of the remaining processing stages of the signal processing chain, it can be evaluated the performance-loss of the overall system. Hence, retaking the example mentioned before, the 16-bit quantized outputs of the FFT result in a performance degradation of the channel estimation (i.e., the precision-loss of

22 Will-be-set-by-IN-TECH 208 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

the estimated coefficients for the pilot tones increases the error during the interpolation stage). Example 3.4 presents the modified version of the MATLAB signal, which accounts for hardware constraints and applies the desired quantization. It is assumed a 14-bit ADC, a QPSK modulation and a value of the pilot signals of ±4/3 (defined in the WiMAX standard). For this testing scenario the DR is set to [−1.9, 1.9]: i.e., 2 bits represent the sign and the integer part and the remaining bits represent the fractional part.

VI *MATLAB/HDL co-simulation*: this section gives representative examples of the MATLAB versus HDL co-simulations, which is a vital procedure that has to be applied in all FPGA prototyping cases. Continuing from the previous example, the digitized IF signal at the receiver (i.e., ADC outputs) will be processed by the DDC component, which comprises a programmable digital synthesizer and a complex Finite Impulse Response (FIR) lowpass filter that eliminates out-of-band components. The input signal at the DDC is multiplied with a sine and a cosine (produced by the digital synthesizer). This multiplication results in the I and Q vector components, which are finally filtered and decimated in order to produced the desired baseband signal. This procedure is considered a key functionality of the Software Defined Radio (SDR). The digital synthesizer can be tuned on-the-fly by accessing a digitally-controlled register. This fact allows designers to correct the CFO, an inherent impairment of real-life RF front-end systems.

**Example 3.4**: MATLAB code that models the constraints introduced by the utilization of a particular ADC.

```
ADC_quantization=quantizer([14 12]);
gain=1.9/max(abs(received_signal));
ADC_samples = (received_signal.*gain)';
ADC_samples_binary = num2bin(ADC_quantization, ADC_samples);
ADC_samples_quantized = bin2num(ADC_quantization,
ADC_samples_binary);
```
Example 3.5 describes how the Xilinx DDC IP core was configured using MATLAB. In more details, we have used the Filter Design and Analysis Tool (fdatool), to design the required low-pass filter and produce the filter coefficients required for configuring the DDC core. Considering the importance of the DDC for the correct operation of the receiver, the MATLAB versus HDL co-simulation provided a crucial contribution for the evaluation of the fixed-point precision and guided the tuning of the configurable parameters featured in the DDC IP core.

**Example 3.5**: the SISO mobile WiMAX receiver requires the design of a low-pass filter with a decimation stage (denoted as polyphase decimator filter in the DDC IP). The configuration parameters of the fdatool are shown in Fig. 10.

The resulting filter has 103 coefficients, which can be quantized and exported to a file (i.e., with file extension .coe). The latter can be used to configure the Xilinx DDC IP core, as depicted in Fig. 11.

```
sin_samples = -ADC_samples.*sin(2*pi*(22.4-eps_freq*22.4/2048)*
(1:length(ADC_samples))/89.6);
filter_cos = conv(cos_samples,hfilter);
filter_sin = conv(sin_samples,hfilter);
baseband_signal = filter_cos(1:4:end)+j*filter_sin(1:4:end);
%----- function end -----
Fig. 12 shows how the digital filtering stage of the Xilinx DDC IP can be configured using
the coefficients file produced in MATLAB.
Figure 12. Configuration of the digital filtering stage of the DDC IP core using the
MATLAB-generated coefficients.
```
Example 3.6 covers the main steps required to verify the behaviour and performance of an independent processing block (built using HDL code), by interfacing it with the MATLAB model of the remaining components of the system. The one-to-one comparison of the HDL model with its MATLAB counterpart provides a reliable analysis of the implementation losses (i.e., fixed-point versus floating point) and facilitates the selection of an optimum quantization (i.e., trade-off between precision and computational complexity, optimization of the bit-alignment and truncation operations).

**Example 3.6**: The MATLAB and VHDL code of the DDC processing stage that is required to run the co-simulation is quoted next. The output of the MATLAB model is written to a file, which is later used as a test vector of the RTL-simulation:

```
%The quantized outputs of the ADC are written to a file, which
will be used to stimulate the DDC IP core.
fileOut=fopen('DDC_core.in','w');
```
MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 25 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 211

```
for k = 1:length(ADC_samples_quantized)
DIN = num2bin(ADC_quantization,(ADC_samples_quantized(k)));
fprintf(fileOut,'%s\n',DIN);
end
fclose(fileOut);
In the following simplified version of the VHDL code of the DDC block, the
MATLAB-generated signal will be used as input to the RTL code. Additionally, the
results produced by the HDL simulation are written to a file. This is used in recursive
manner for the MATLAB simulation of the remaining processing blocks of the receiver:
as inputs to the DDC IP core.
FILE inputFile : TEXT OPEN READ_MODE IS "DDC_core.in";
used to stimulate the MATLAB model.
FILE outputFile : TEXT OPEN WRITE_MODE IS "DDC_RTL.out";
DDC_core_ins : DDC_core PORT MAP (
 -Input ports
CLK => clock_adc,
SEL => reset,
DIN => data_in,
ND => data_valid_in,
LD_DIN => prog_DDS_value,
ADDR => prog_DDS_addr,
WE => prog_DDS_write_enable,
 -Output ports
RFD => ready_for_data,
RDY => output_ready,
DOUT_I => BB_I_comp,
DOUT_Q => BB_Q_comp);
PROCESS
VARIABLE L_IN : LINE;
VARIABLE DATA : STD_LOGIC_VECTOR(13 DOWNTO 0);
BEGIN
reset <= '1';
data_in <= (others => '0');
data_valid_in <= '0';
prog_DDS_addr <= cnt_DDCreg;
WAIT FOR 44.64 ns;
reset <= '0';
data_valid_in <= '1';
```
26 Will-be-set-by-IN-TECH 212 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

```
FOR k IN 0 TO cnt_lengthDDC LOOP
READLINE(inputFile,L_IN);
READ(L_IN, DATA); data_in <= <= DATA;
WAIT FOR 11.16 ns;
END LOOP;
WAIT;
END PROCESS;
PROCESS(clock_adc)
VARIABLE L_OUT : LINE;
BEGIN
IF RISING_EDGE(clock_adc) THEN
IF output_ready = '1' THEN
WRITE(L_OUT, BB_I_comp);
WRITELINE(outputFile, L_OUT);
WRITE(L_OUT, BB_Q_comp);
WRITELINE(outputFile, L_OUT);
END IF;
END IF;
END PROCESS;
When comparing the 32-bit words at the output of the HDL-based DDC processing
block with the equivalent stage of the MATLAB model, we realize that we may truncate
this word to 16 bits with negligible precision losses. The required quantization is also
obtained during this stage. Finally, in order to use the HDL-generated outputs in the
MATLAB-simulation of the remaining blocks of the receiver, the following MATLAB
code is required:
inputs to the MATLAB receiver.
fileIn=fopen('DDC_RTL.out','r');
VHDLResult=fscanf(fileIn,'fclose(fileIn);
DDC_quantization=quantizer([32 26]);
BB_I_comp=[];
BB_Q_comp=[];
k=1;
for l=1:(cnt_lengthDDC+1)/2
binTmp=VHDLResult(k:k+31);
BB_I_comp(l)=bin2num(DDC_quantization,binTmp);
k=k+32;
binTmp=VHDLResult(k:k+31);
BB_Q_comp(l)=bin2num(DDC_quantization,binTmp);
k=k+32;
end
```
MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 27 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 213

VII *Data post-processing*: Once the FPGA-based prototype presents a stable operation, data can be captured in different parts of the system to evaluate its performance. This data could then be processed in MATLAB to calculate the desired metrics. When the goal is to characterize the performance of a system under mobility conditions, hundreds of data captures (e.g., generated with different channel seeds) containing several complete frames have to be captured and processed under different operating conditions (e.g., modify the SNR). MATLAB can be used to automate the calculation of the performance metrics, as shown in example 3.7.

**Example 3.7**: A simplified version of a MATLAB function, which automates the calculation of the EVM. The function relies on a predefined name-structure for reading the files: %Function to automate the calculation of the EVM from real-time post-equalization data captures. function automatic\_EVM\_calculation(channel\_spec, initial\_rep, final\_rep, SNR\_steps) EVM\_experiment=[]; for repetition = initial\_rep:final\_rep for scenario = 1:SNR\_steps %Generation of a predefined 'file\_name' file\_name=['postequal\_' channel\_spec '\_' SNR\_step '\_' num2str(repetition)]; %Call to the function calculating the EVM EVM\_array=EVM\_calculation\_HW\_capture(file\_name); %Calculation of the mean value, conversion to dB and storage EVM\_experiment(index,scenario)=10\*log10(mean(EVM\_array)); end index=index+1; end save(['postequal\_' channel\_spec '\_' SNR\_step '\_' num2str(initial\_rep) '\_to\_' num2str(final\_rep) '.mat'],'EVM\_experiment'); %----- function end -----

28 Will-be-set-by-IN-TECH 214 MATLAB – A Fundamental Tool for Scientifi c Computing and Engineering Applications – Volume 2

> The EVM calculation of the FPGA-based prototype is made possible by comparing the files captured in the equalization block with the equivalent ones of the ideal MATLAB receiver. To achieve this we have to feed the MATLAB model with all the different test vectors captured in the post AGC stage of the FPGA prototype and produce the same amount of files at the output of the equalization stage. For each OFDM symbol in each captured frame, we would apply the following MATLAB operations (a mean value for each captured-file has to be calculated in the end):

```
deviation=[];
for index=1:cnt_data_carriers_per_symbol
deviation(index)=equal_out_RTL(index)-ideal_equal(index);
end
EVM_symbol=mean(abs(deviation).ˆ2)/1;
```
### **4. Conclusion**

The message that this chapter intended to convey is that MATLAB is having nowadays a diverse usage that goes beyond its initial conception as a generic mathematic modeling environment. Its functionality is valuable because it can be directly interfaced with various third party software/hardware design tools and instruments. Moreover, MATLAB has a multi-level contribution in the conceptual high-level modeling of a system, and it is an ideal candidate for rapid prototyping, since it can emulate the baseband signal processing when used in instrumentation-based offline testbeds. MATLAB is also used to emulate real-life hardware constraints and it can be adapted to serve HDL co-simulations. Its role is particularly important for the prototyping of bit-intensive systems such as the PHY-layer of modern wireless communication systems. This chapter proposed a comprehensive design methodology and quoted indicative examples, in order to highlight the previously mentioned benefits of MATLAB. In concrete, this chapter provided a guideline for the use of MATLAB during the prototyping of a FPGA-based real-time transceiver based on the mobile WiMAX standard. Finally, its critical contribution was contemplated by quoting extracts of the source code of the previously mentioned system prototyping phases.

### **Acknowledgements**

The research leading to the published work was partially supported by the European Commission under projects BuNGee (248267) and BeFEMTO (248523); by the Catalan Government under grant 2009 SGR 891; and by the Spanish Ministry of Economy and Competitiveness under projects TEC2011-29006-C03-01 (GRE3N-PHY) and TEC2011-29006-C03-02 (GRE3N-LINK-MAC).

# **Author details**

Oriol Font-Bach, Nikolaos Bartzoudis and David López Bueno *Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain* MATLAB as a Design and Verification Tool for the Hardware Prototyping of Wireless Communication Systems 29 MATLAB as a Design and Verifi cation Tool for the Hardware Prototyping of Wireless Communication Systems 215

Antonio Pascual-Iserte

*Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain Department of Signal Theory and Communications, Universitat Politècnica de Catalunya (UPC), Spain*

# **5. References**

	- [17] O. Font-Bach, N. Bartzoudis, A. Pascual-Iserte, and D. López Bueno. Prototying Processing-Demanding Physical Layer Systems Featuring Single Or Multi-Antenna Schemes. In *Proc. European Signal Processing Conference (EUSIPCO)*, September 2011.
	- [18] *CTTC, GEDOMIS® testbed*. http://engineering.cttc.es/gedomis, 2012.
	- [19] IEEE 802.16e-2005. IEEE Standard for Local and Metropolitan Area Networks. Part 16: Air Interface for Fixed Broadband Wireless Access Systems. Amendment 2: Physical and Medium Access Control Layer for Combined Fixed and Mobile Operation in Licensed Bands, 2005.